NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/76

Internet Message Format | 1996-08-06 | 3.8 KB

Path: lyra.csx.cam.ac.uk!nmm1
From: [e-mail] (Nick Maclaren)
Newsgroups: comp.std.c,comp.arch.arithmetic,sci.math.num-analysis
Subject: Why is <float.h>? [was Re: sizeof(1L) in preprocesor ...]
Date: 10 Jan 1996 23:19:03 GMT
Organization: University of Cambridge, England
Distribution: inet
Message-ID: <4d1hh7$[e-mail]>
References: <[e-mail]> <4ctk66$[e-mail]> <[e-mail]> <4ctpkv$[e-mail]>
NNTP-Posting-Host: apus.cus.cam.ac.uk

I was asked (by Email) to explain why the values in <float.h> are
expressions that evaluate to rvalues, and why this is imbecilic.
Please ignore this if you know, and flame me if you feel the urge!


The Intel 8087 and similar chips have operations that allow a program
to change the rounding modes, exception handling and even effective
mantissa length.  They do not have an operation to change the radix,
as was once proposed for the IBM 370 architecture (but never, as far
as I know, implemented).

During the design of the ANSI standard, the 'PC camp' insisted that
the values in <float.h> had to be general rvalues to allow for this.
The traditionalists and numerical analysts argued for the values to
be preprocessor constants, as in all the other headers, but lost.  I
was a very minor member of the latter camp.

I know of no C run-time system that has taken advantage of this aspect
of the standard to support dynamically reconfigurable arithmetic; it
would be possible to implement, but there are very, very few people
capable of it.  And that is even before you allow for the possibility
of the arithmetic properties being changed in an asynchronous signal
handler :-)


So why is this imbecilic?

Numerical analysts use values of the sort that are found in <float.h>
for many purposes, including:

    1) Switching to alternate algorithms for special functions.
    2) Avoiding overflow, underflow and rounding error.
    3) Selecting appropriate precisions for conversion on I/O.
    4) Varying the algorithm in the rare cases where it matters.

Now, (1) needs the values to be preprocessor constants for efficiency.
Remember that such people are the very people who write the functions
called via <math.h>, and we like to be able to write code that compiles
automatically and correctly even on machines that we have never heard
of!  But to do this efficiently, we have to define our OWN <float.h>,
which isn't portable!

For categories (2)-(4), efficiency is not crucial.  But it is rare
that the values need be exact, either.  And any numerical analyst
worth his salt is quite capable of calculating the values himself,
and so doesn't need <float.h> in the first place.  Anyway, we don't
trust run-time system authors, for very good reasons.  You wouldn't
believe how many systems have the values in <float.h> wrong!

So <float.h> is, at best, a minor convenience to numerical analysts.

End users who are not numerical analysts need the values in <float.h>
for reasons (2)-(4) and similar ones.  But they don't need the detail
that it provides - they need only an indication of the accuracy, an
indication of the maximum value, and some flags indicating whether
underflow/overflow/etc. are handled in a sensible fashion (which
aren't specified in <float.h>, anyway).

So <float.h> is vastly more complex than end users need.


I speak as someone who has written functions in <math.h>, who has
also written a C run-time system, who writes software that uses
<float.h> and who writes codes that tests <float.h>.  And I still
haven't found any justification for its existence in its current
form.

So, am I being unreasonable when I am rude about it?


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  [e-mail]
Tel.:  [phone]    Fax:  [phone]